Subject: Security comments

From: [email-masked] (Denis PINKAS)
Date: Thu, 17 Jun 93 18:24:57 EET

June 17, 1993

Comments on document ciw3party
(Exploitation of distributed security in SNA LU 6.2 conversations)

The short period of time between the date the document was made available 
and the date the meeting took place did not allowed us to prepare comments 
so that they could be available for the meeting. Unfortunately, we have been 
unable to send a representative to attend the CPI-C implementor's workshop, 
so we would be interested to get some information about the discussions 
related to security in the June meeting. Nevertheless, it is not too late to 
send some comments on the document. 

General comments

1- The document is focused on authentication and thus does not address to 
other major topics: integrity and integrity + confidentiality. It seems as 
important to cover these two aspects.

2 - The extensions are designed with a single security mechanism in mind: 
DCE 1.0. The extensions should be opened for evolutions of DCE and for other 
security mechanisms. It is expected that the security protocols of DCE 1.1 
will be different from the security protocols of DCE 1.0 and thus evolutions 
need to be possible. In addition it should also be possible to use a 
different security mechanism like Kerberos, Kryptoknight or SESAME. 
Note that the scope says: " The architecture is flexible enough that any 
services could be used to build the security-related fields, as long as the 
information supplied by the originating security service is understood by 
the destination security service".

3 - The document mentions the support of ESSI. The relationship between the 
document and the use of ESSI is not straight-forward. At the moment there is 
another set of APIs able to handle very similar functions: they are known as 
GSS-APIs (from IETF) or Base GSS-APIs from X/Open (they will be issued as a 
preliminary specification). Some rational for choosing ESSI and not GSS-APIs 
should be given. Also, GSS-APIs are not yet casted in concrete: minor 
changes could be made if some functions are lacking.

4 - There are two main goals: get rid of all passwords sent in the clear 
over a communication line and allow for delegation (proxy) control. The fist 
goal is well addressed while the second is not covered enough: ways are 
lacking to specify how delegation should be handled. A caller must be able 
to specify whether or not the correspondent should be allowed to delegate 
any further; if yes, what kind (i.e. types) of correspondents are eligible 
for delegation, and, with a lower priority, what kind of restrictions can be 
specified.

5 - Since DCE allows the support of group-memberships, it is questionable 
whether we should allow to make these groups visible to the applications: a 
ticket carries much more than simply an identity. In a generalized way, 
should we allow to select / obtain security privileges (e.g. group-
membership, clearances) ? If not, what would be the policy: to send all 
privileges (which violates the principle of least privileges) or to send 
only the identity ?

Detailed comments

At the moment two security levels are defined:

SECURITY_SAME and SECURITY_PROGRAM

SECURITY_PROGRAM where a password is used, and thus is not usable for 
delegation. This level is basically kept unchanged.

SECURITY_SAME where no password is used, but where currently the identity is 
transmitted. This level could be enhanced to support token transmission but 
these tokens MUST not imply the use of a SINGLE security mechanism.

Additional levels are proposed: AUTH-EVERY and MUTUAL. This appears as 
insufficient.

AUTH-EVERY means that on every ATTACH authentication must occur. Whether it 
is light authentication (authenticator only) or full authentication 
(authenticator and ticket) is another matter which is mechanism dependent. 

This must be balanced over the fact that INTEGRITY or 
INTEGRITY/CONFIDENTIALITY need also to be considered. This comes in addition 
to AUTH-EVERY. There are different scenarios which relates to different 
security policies:

A - Mutual authentication must occur before any data is sent over the 
communication.

This has different sub-cases:

A.1.- Only authentication is available:

Authentication is performed, and data is sent unprotected (this is MUTUAL-
AUTH)

A.2. - Integrity is available (in addition to authentication):

Mutual authentication is performed, then data is sent integrity protected 
(this is MUTUAL-AUTH&INT).

A.3. - Integrity and confidentiality are available (in addition to 
authentication):

Authentication is performed, data is sent integrity and confidentiality 
protected (this is MUTUAL-AUTH&INT&CONF).

B - Mutual authentication is not necessary before data can be sent over the 
communication. This has different sub-cases:

B.1.- Only authentication is available:

Authentication is performed, and data is sent unprotected (this is 
UNILATERAL-AUTH)

B.2. - Integrity is available (in addition to authentication):

Authentication is performed, data is sent integrity protected (this is 
AUTH&INT.

B.3. - Integrity and confidentiality are available (in addition to 
authentication):

Authentication is performed, data is sent integrity and confidentiality 
protected (this is AUTH&INT&CONF).

Later on, the correspondant will have to use protections which are related 
to the security level:

	Integrity	Confidentiality

- MUTUAL-AUTH	No	No
- MUTUAL-AUTH&INT	Yes	No
- MUTUAL-AUTH&INT&CONF	Yes	Yes
- UNILATERAL-AUTH	No	No
- AUTH&INT	Yes	No
- AUTH&INT&CONF	Yes	Yes

This approach leads to recognize six levels instead of only two.

It is also needed to signal /indicate the security mechanism being used need 
to be added, e.g. to make a difference between Kerberos V4, Kerberos V5, DCE 
1.0, DCE 1.1, X 509, etc ... A single bit is not sufficient.

Comments page by page

Page 9. The text under the security level SAME assumes that a single 
mechanism is used, which is in contradiction with the goals mentioned in the 
section 1.0.

Page 9. The first bullet under the bullet SAME mentions: if the partner 
indicated authenticator required on every attach (how is this indicated ?), 
then send signon list key (what is this ?, is the list protected ?) ...

Page 11. The second sentence at the bottom of the page says: The 
authentication level can be specified in several places ...
Is it really an authentication level or a security level instead ?

Page 15. Our understanding is that the new bit in BIND is more to request a 
challenge (also called a nonce) so that, if the underlying security 
mechanisms needs it an exchange can be saved. It does not indicate "support 
for the new distributed system features."

The nonce can or cannot be used. This is security mechanism dependant.

Page 15. The note in 5.3.2. is not fully understandable. Does this means 
that only the ATTACH get the sequence number, not other flow of information 
? What kind of threat is supposed to be covered here ?

Page 16. Using the signed on From List allows to save the sending of a 
ticket in some cases but increases the burden of the management of such 
lists. The question (translating a French proverb) is whether or not "the 
game is worth the candle". Although the ticket is not specially short, it 
can make sense to avoid all the burden. Coordination of LU's add some extra 
protocols which can counter-balance the advantages. Do we have some figures 
about the real advantage to support this ?

Page 17. More than one security type can be indicated for one target 
principal name. This should be stated more clearly.

Page 17. On page 11, it is said that the option actually used will be the 
highest specified in any of the places available at the sending side. This 
is in contradiction with the sentence which says that the directory sets a 
default that the application can override.

Page 32. Delegation (called here forwarding) as proposed is rather crude. 
Different delegation schemes can be considered:

1 - No delegation: the correspondent is not allowed to delegate.

2 - impersonation: the correspondent is allowed to delegate everywhere. This 
assumes a high level of trust in the delegate.

3 - simple delegation: the correspondent is allowed to delegate only to some 
correspondents. The last-level application "sees" only the first application 
but not the intermediates.

4 - traced delegation: the correspondent is allowed to delegate only to some 
correspondents. The last-level application "sees" not only the first 
application but also all the intermediates.

For simple delegation or traced delegation, a delegate may further restrict 
the list of next delegates. This means it has first to get information about 
the next delegates.

Some means to handle these cases have to be provided. If this may be agreed 
in principle then we may work out the details of how to handle it.

For general information, I will send in a separate mail the definition of 
the Extended GSS-APIs. These APIs have been presented to the X/Open Security 
Working Group by the SESAME consortium (Bull, ICL, SNI) and will be 
circulated as an X/Open snapshot document once some additional tutorial text 
will be added. In the mean time, this document may be useful as it provides 
also some guidance about the use of the Base GSS-APIs.

Denis

-- 

============================================================================
      Denis Pinkas, Bull S.A                 E-mail : [email-masked]
      System Design                                               
      7, Rue Ampere                           Phone : (33-1) 69 93 95 75
      91343 MASSY Cedex, France                Fax  : (33-1) 69 93 73 53
============================================================================